Note: This video and podcast was generated using AI, adapting the original content and technical insights created by the author of this article.

Insights from platform engineering experts at DevOpsCon New York help understand the implications for internal developer platforms and the teams building them.

AI agents can increasingly take on work that once required developers to navigate the interfaces themselves, but they don’t need to follow a guided workflow through a portal. They need programmatic access to the capabilities behind it. As principal technologist at Broadcom, Jad El-Zein puts it, “When the human is not the consumer, it changes everything.” 

For platform engineering, that creates a new design problem: What is the platform once we stop defining it primarily through the experience of the developer?

The Internal Developer Platform Was Built for Humans

That human-centered design was the goal of platform engineering.

Dilpreet Bindra, Senior Director of Engineering at Broadcom, describes reducing the cognitive load on application developers as one of the original goals of platform engineering. Instead of expecting developers to understand every infrastructure decision behind their applications, platform teams began packaging that complexity into something easier to consume.

The internal developer portal became the most visible expression of that idea. It brought infrastructure services, templates and approved workflows into one place, allowing developers to use them without having to understand every system involved. 

That arrangement addresses very human problems: attention is limited and choices create cognitive load. Therefore, context has to be presented in a form that helps someone decide what to do next. But a guided interface designed to help humans make decisions doesn’t necessarily provide that information in a form an agent can use.

The Human Interface Doesn’t Translate to Agents

Take a routine task such as deploying a new service. A developer might open the company portal, select a template, choose an environment and follow a recommended path. The platform automates much of the work, but the interface still has a job: make the available choices legible and steer the developer toward a sensible outcome.

An agent has little use for that journey. It needs to know which capabilities are available, how to call them and what the platform returns. As El-Zein puts it, “The agent just wants to hit the API and do its thing based on what it’s out to accomplish.” If an IDP exposes its capabilities only through human-oriented workflows, the developer experience and the platform have become too entangled. 

El-Zein uses an easy image for this problem: he warns that golden paths can become “golden cages” when the same workflows designed to simplify life for developers are applied unchanged to agents.

Learn more: If you want to continue the discussion around what comes next now that AI agents are becoming platform users, the AI Platform Engineering Day at DevOpsCon Munich offers both focused sessions and a chance to go deeper in conversation.

The program includes talks such as:

• The Sovereign Engineer: Making Agents Responsible for Human Understanding and Judgement — Russell Miles
• Forget the Portal: Designing Headless, Intent-Driven Developer Platforms — Hosein Salahi
• Federated Platforms: Platform Adoption the Star Trek Way – Johannes Rudolph

A particular highlight is the Roundtable Discussion at AI Platform Engineering Day. Rather than only listening to presentations, participants can discuss the day’s key questions directly with speakers and fellow attendees. It is a chance to compare approaches, ask questions, and bring your own platform challenges into the conversation.

What Defines the Platform? 

Separating the developer experience from the underlying platform shifts the focus to what the platform must provide independently of any particular interface. 

The capabilities it provides are an obvious starting point. Provisioning infrastructure, deploying applications or retrieving operational information are functions that developers have traditionally accessed through self-service workflows. An agent needs access to those same capabilities, but exposing an API is not enough to make them usable.

The missing ingredient is often context. In their talk, Nomura engineers Suresh Veda and Sid Choudhury illustrated why this matters: internal developer surveys at the financial services company found that engineers spent less than a quarter of their time actually coding. Much of their work involved understanding requirements, application architecture, dependencies and the systems surrounding their applications. To make that information more accessible, Nomura has been developing an internal knowledge graph that brings together application metadata and architectural information, with MCP providing a way for AI tools to access it.

Equifax platform engineers Hrushikesh Pokala and Sumanth Mothkuri presented another example of how agents can access the context they need. Their MCP-based orchestration model brings together live platform state and information from systems such as GitHub, Jira and ServiceNow. An agent can query the environment and compare its current state with the configuration and change records that describe how it should look. Rather than relying on a static set of instructions, it can work with information drawn from the systems themselves.

Pokala and Mothkuri also demonstrated how governance can be built into the workflow: when an agent was asked to bypass the approval process for a production deployment, it refused the request. The approval requirement was enforced as part of the process rather than left to the discretion of whoever initiated it. The requirement extends beyond deployment approvals. Jad El-Zein highlights non-human identity and delegated permissions, while Bindra calls for role-based access control and observability. 

These examples point to three elements of a platform: capabilities, context and controls. Consumers need functions they can invoke, reliable information about the systems those functions affect, and enforceable rules governing their actions. 

Bindra’s call for platforms to be “composable by design” points toward a practical consequence: the same capabilities, context and controls can support a guided developer experience or be made accessible to agents through APIs and tools. 

Learn more: Want to explore how platform engineering teams are adapting to AI agents, how European companies are working toward digital sovereignty, and which skills software engineers will need in an AI-driven world? DevOpsCon Munich brings these topics together through sessions that explore the challenges and practical approaches. 

The program includes talks such as:

• AI Platform Engineering: The Future – Max Körbächer
• Platform Engineering your way to Sovereignty — Johannes Rudolph
• AI Literacy for Developers: Thinking Clearly While AI Writes the Code — Russell Miles

One Platform, Many Consumers

Bindra’s vision of Platform Engineering 2.0 is explicitly multi-persona. Application developers remain important consumers, but platforms increasingly have to account for others around the software delivery process as well: from ML and data specialists to security and compliance functions, engineering and business leaders, and autonomous agents.

Those groups don’t necessarily need the same view of the platform. A developer may care about getting a service into production without mastering the infrastructure underneath. A security team needs a different kind of visibility. An engineering leader may need to understand cost or operational performance. An agent needs capabilities and context in a form software can consume directly.

In her talk, Garima Bajpai, founder of the Canada DevOps Community of Practice, warned against the proliferation of disconnected AI point solutions and argues for a more integrated engineering environment. If every new persona gets its own stack, platform engineering simply recreates the fragmentation it was meant to reduce. 

Platform teams must decide which capabilities and engineering context should be shared, which controls must apply across consumers, and where separate interfaces are justified. Otherwise, they risk building parallel platforms that become increasingly difficult to maintain consistently. 

A Platform That Can Welcome Its Next Consumer

AI agents provide a practical test of how reusable a platform really is. When a new consumer needs access, can the existing capabilities, context and controls support it? Or must teams create new integrations, duplicate information and establish separate governance mechanisms?

That suggests another measure of platform quality alongside developer productivity and reduced cognitive load: how readily the platform can accommodate a new consumer without recreating the foundation beneath it.

For platform engineers, the challenge is deciding what should remain common across consumers and what needs to change for each one. How can they give agents greater autonomy without losing control? And how can they accommodate new ways of interacting with the platform without building another layer of complexity around each new consumer?

AI agents make these questions urgent, but they are unlikely to be the last consumers to challenge today’s assumptions. The task is not simply to make platforms work for agents, but to avoid making agents the next constraint they are built around.

If you want to explore the questions in this article further and compare how others are approaching platform engineering for AI agents and other consumers, DevOpsCon Munich offers two focused opportunities: the AI Platform Engineering Day and the Platform Engineering Summit, taking place as part of the conference from November 30 to December 4.